Systems, apparatus, and methods for configuring device data streams

ABSTRACT

Configuring device data streams (DDSs) of a mobile device is described herein. DDSs can include sensor data (captured from one or more sensors of the mobile device) and user-specific data (including application data from applications executed via the mobile device, as well as non-application data). DDS configuration parameters define modifications for the user-specific data and/or the sensor data of the DDS; these modifications can include removing or altering the user-specific data and/or the sensor data. DDSs can be sent to an external storage device via a network, and DDS modifications can be made at the mobile device or at the external storage device. Modified DDSs can be provided to requestors, and thus, the DDS configuration parameters allow a user to control what data is, or is not, included in a DDS for reasons related to privacy, data usage, etc.

TECHNICAL FIELD

The present application relates generally to the technical field of dataprocessing and, in particular, to processing device data streamscomprising user-specific data and data captured via one or more sensorsor modules of a mobile computing system.

BACKGROUND

A mobile computing device may execute one or more applications thatfacilitate shopping, banking, accessing web based services, or engagingin electronic transactions via the mobile computing device. Dataaccessed and utilized by these applications can includeapplication-specific data (e.g., payment transactions and user log-ininformation) and/or sensor captured data (e.g., location orenvironmental data). However, these applications are often confined to asecurity “sandbox” that isolates application programs, preventingmalicious or malfunctioning programs from damaging or snooping on therest of your computer system. The sandbox may provide a tightlycontrolled set of resources for guest programs to run in, so thatnetwork access, the ability to inspect the host system, or the abilityto read from input devices are disallowed or heavily restricted. Thus,access to data used by each application can also be heavily restricted.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present disclosure are illustrated by way ofexample and not limitation in the figures of the accompanying drawings,in which like reference numbers indicate similar elements, and in which:

FIG. 1 is an illustration of a system for creating, transmitting, andreceiving one or more device data streams of a mobile computing deviceaccording to an embodiment of the disclosure.

FIG. 2 is a flow diagram of a process for editing and transmitting adevice data stream according to an embodiment of the disclosure.

FIG. 3 is a flow diagram of a process for receiving, configuring, andtransmitting a device data stream according to an embodiment of thedisclosure.

FIG. 4 is an illustration of a plurality of sets of data streamconfiguration parameters according to an embodiment of the disclosure.

FIG. 5 is a flow diagram of a process for generating a compensationvalue for a user based on a configured device data stream according toan embodiment of the disclosure.

FIG. 6 illustrates one example for a computing device in accordance withaspects of the disclosure.

FIG. 7 is a block diagram illustrating components of a machine,according to some example embodiments, able to read instructions from amachine-readable medium and perform any one or more of the methodologiesdiscussed herein, according to aspects of the disclosure.

DETAILED DESCRIPTION

The description that follows includes illustrative systems, methods,techniques, instruction sequences, and computing machine programproducts that embody illustrative embodiments. In the followingdescription, for purposes of explanation, numerous specific details areset forth in order to provide an understanding of various embodiments ofthe inventive subject matter. It will be evident, however, to thoseskilled in the art, that embodiments of the inventive subject matter canbe practiced without these specific details. In general, well-knowninstruction instances, protocols, structures, and techniques have notbeen shown in detail.

The methods or embodiments disclosed herein can be implemented as acomputer system having one or more modules (e.g., hardware modules orsoftware modules). Such modules can be executed by one or moreprocessors of the computer system. The methods or embodiments disclosedherein can be embodied as instructions stored on a machine-readablemedium that, when executed by one or more processors, cause the one ormore processors to execute the instructions.

FIG. 1 is an illustration of a system 100 for creating, transmitting,and receiving one or more device data streams of a mobile computingdevice according to an embodiment of the disclosure. A system 100 isillustrated as including a user 110, a mobile computing device 115 (usedby the user 110), and a data stream storage 120 to store device datastreams from one or more users. All components of the system 100(including additional components of the system 100 described in furtherdetail below) are communicatively coupled via a network 105.

The mobile computing device 115 can comprise a smart phone, personaldigital assistant (PDA), laptop, a wearable computing device such as aheads-up display (HUD) device, or any similar mobile electronic devicecapable of some form of data connectivity. The mobile computing device115 can create (and or edit) one or more device data streams. A devicedata stream can comprise any combination of user-specific data and datacaptured via sensors of the mobile computing device 115. Sensor-captureddata can include biometric data, audio data (e.g., via an audio sensorsuch as a microphone), image data (e.g., photo, video, or any other typeof image data via an image sensor such as a camera), and/or location,direction, and environmental data (e.g., temperature, pressure,humidity, orientation, velocity, acceleration, compass bearing, volume,latitude and longitude, Global Positioning Satellite (GPS) data, etc.).User-specific data (other than the above described sensor data) cancomprise application data related to one or more applications executedby the user 110 via the mobile computing device 115. User-specific datacan also comprise any other data specific to the user 110 (e.g., logincredentials, user email, user phone number, etc.). The mobile computingdevice 115 can transmit one or more device data streams to be stored bythe data stream storage 120 periodically, continuously, manually, etc.The data stream requestors 150 and 155 can request data streams from thedata stream storage 120.

For example, either of the data stream requestors 150 and 155 canexecute a data matching service to aggregate device data streams into auser data stream. The data stream matching service can receive devicedata streams generated by the mobile computing device 115 (e.g., fromdevice sensors, from applications registered to the user 110, etc.). Thedata stream matching service can generate, based on the sensor readingsand/or activity classifications received from the mobile computingdevice 115, data including a context that is specific to the operationof the mobile computing device 115 (e.g. the degree of mobility of theuser 110 during execution of one or more applications, the physicallocation of the mobile computing device 115, etc.). The data streammatching service can identify which of its received data streams arerunning on a same physical hardware processing device (i.e., mobilecomputing device 115) by comparing the application data streams storedin data stream storage 120 to the context to find the data streams thatmatch the context. The data stream matching service may be configured tomatch these data streams (or to match these data streams within acertain margin of error).

For example, the data matching service can execute a pattern matchingprocess to look for patterns and generate an inference for the sensordata—e.g., hours-long non-moving GPS sensor data captured in the middleof the night is probably the user's “home,” while non-moving GPS sensordata captured in the middle of a weekday is probably the user's “work.”

Multiple device data streams that match can be grouped into a singleuser data stream. This aggregation process can automatically handleusers with multiple devices, changing devices etc.

The mobile computing device 115 may execute a plurality of applicationsto access a plurality of different services via the network 105. Theseapplications can include applications for accessing services—e.g., anonline service provider 140 and a purchasing service associated with amerchant 130. The online service provider 140 can utilize sensor datacaptured by the mobile computing device 115 to provide a service to theuser 110. For example, geo-location data captured by the mobilecomputing device 115 can be used for navigation services, environmentaldata services such as weather, etc. The merchant 130 having a physicalretail location can utilize various computer systems, such as aninventory system 132 or a point of sale (POS) system 134, among others.For example, the purchasing service can be accessed via an applicationand can work with both a POS system 134 and inventory system 132 of themerchant 130 to obtain access to inventory available at the retaillocation, and enable the merchant 130 to provide payment services.

Each of the plurality of applications executed by the mobile computingdevice 115 may utilize various application-specific data andsensor-captured data. Each of the applications can also be run in a“sandbox” such that they may not easily see or communicate with othersof the plurality of applications. Applications running on mobilecomputing devices are often confined to a security sandbox that isolatesapplication programs, preventing malicious or malfunctioning programsfrom damaging or snooping on the rest of the computer system. Thesandbox may provide a tightly controlled set of resources for guestprograms to run in, so that network access, the ability to inspect thehost system or read from input devices are disallowed or heavilyrestricted. Isolation can be at multiple levels, including machineisolation, virtual machine isolation, process isolation, secure accountswith limited access rights, and application domain isolation withinprocesses using local security mechanisms, etc. Applications can beexecuted with any combination of isolation levels. Isolated sandboxexecution environments can be executed based on rules or settings todetermine what processes can be started or spawned, and to define accessto resource entities such as data files, network connections, hardware,etc.

Furthermore, while this exemplary embodiment describes the device 115 asa mobile computing device, desktop computer operating systems can runcertain applications in a sandbox; for example, most web browsers runweb pages in a sandbox that restricts them to running in a browser andaccessing a limited set of system resources. This sandboxing providesthe benefit that, even if a web page was able to take advantage of somesecurity vulnerability of the browser, it would still have to escape thebrowser's sandbox to do any real damage.

Because applications executed via the mobile computing device 115 may berunning in a sandbox, it is often difficult to get them to interactseamlessly as a user proceeds through the steps of a more involvedelectronic transaction that may use multiple applications to fullycomplete. For example, a user may be prompted for login informationseveral times as they run several applications. A first application maybe used to log into a user account at a merchant web site and browseproducts that are typically sold and/or auctioned using the “shoppingcart” model that allows a customer to select an item from an electroniccatalog and then metaphorically add the selected item to a shoppingcart. When the customer is done selecting items, the customer requeststhat the items in the shopping cart be “checked out.” At this point, apayment transaction is initiated, and the purchaser is asked to providebilling information such as a credit card number and other confidentialinformation. A second application might then be used to access a thirdparty online payment service (e.g., PayPal®) for handling paymenttransactions, and at this point the user is usually prompted for log-ininformation related to the user's online payment service account.

The data used within these sandboxes may comprise device data streams.Device data streams stored by the data stream storage 120 can beprovided to data stream requestors 150 and 155 to match these differentapplications to the mobile computing device 115. The data streams caninclude user-specific data (including application-specific context data)and/or various device sensor readings captured via the mobile computingdevice 115. For example, the above described data stream matchingservice can receive data streams from each of a plurality applicationsexecuted via the mobile computing device 115 (e.g., from applicationsregistered to the user 110). These data streams can include the abovedescribed sensor data, or the sensor data can be received as a separatedata stream. The data stream matching service can generate, based on thesensor readings and/or activity classifications received from the mobilecomputing device 115, data including a context that is specific to theoperation of the mobile computing device 115 (e.g. the degree ofmobility of the user 110 during execution of one or more applications,the physical location of the mobile computing device 115, etc.). Thedata stream matching service can identify which of its received datastreams are running on a same physical hardware processing device (i.e.,mobile computing device 115) by comparing the application data streamsstored in data stream storage 120 to the context to find the datastreams that match the context. The term “context” can refer toenvironmental inputs (e.g. sensor readings) such as location, time, andweather conditions, among others. The context generally refers toconditions describing an individual's (e.g. user's) environment and/oractivities. For example, context information may include a user'slocation, direction of movement, current activity (e.g. walking,driving, on bicycle, etc.), current weather conditions, time of day, andtime of year (e.g. season), among other things. In the followingexamples, context may be used to determine if multiple applications areoperating on a same processing device (e.g. smart phone). For example, amobile shopping application and a mobile online payment serviceapplication may be determined to be running on a same device (andtherefore it may be inferred that they are being run by the same user)if the sensor data the applications transmit regarding the device user'senvironment and/or activities demonstrates that the applications areoperating in the same context.

Device data streams captured via the mobile computing device 115 mayalso be used to resolve application ambiguities. For example, if theonline service provider 140 provides a geo-location based service, itcan have a limited accuracy for determining the location of user 110either due to limitations of the sensor or limitations of an executedalgorithm (e.g., GPS, WiFi or cell tower triangulation, etc.). Forexample, if a user is at a shopping mall comprising a large number of amerchants included in a (relatively) confined space, a geo-locationbased alone may not be able to determine the precise location of theuser 110 within the shopping mall, data associated with servicesprovided by merchant 130 may be used to further specify the user'slocation. Furthermore, the geo-location based service can have erroneousdata due to sensor malfunction or algorithm inaccuracy (e.g., cell towertriangulation inaccuracies due to cellular connectivity issues).Additional data from other applications executed via the mobilecomputing device 115 may be used to resolve such inaccuracies.

Thus, increasing the data provided to the data stream requestors 150 and155 can, for example, increase the accuracy of user activitylogging/tracking services. However, users may be reluctant to providedevice data streams related to their mobile computing devices due toprivacy concerns. Services may also not wish to receive data from allsensors/applications of a mobile computing device. Furthermore, devicedata streams may have inaccuracies (e.g., noise) that is difficult toresolve via machine-learning algorithms (e.g. smoothing the normaljitter of GPS locations into averaged locations over some parameters).Providing logic, modules, or processes to configure device data streamsprior to their transmission to the data stream storage 120 (orsimilarly, allow parameters to be transmitted to the data stream storage120 to authorize what data may be transmitted to the data streamrequestors 150 and 155) can help encourage users to provide device datastreams related to their mobile computing devices. Furthermore, devicedata stream configuration parameters can be applied for all sensor anduser-specific data related to all applications executed via the mobilecomputing device, regardless of as to their execution environment (e.g.,applications executed within isolated sandbox execution environments).

FIG. 2 is a flow diagram of a process for editing and transmitting adevice data stream according to an embodiment of the disclosure. Logicalflow diagrams as illustrated herein provide examples of sequences ofvarious process actions. Although shown in a particular sequence ororder, unless otherwise specified, the order of the actions can bemodified. Thus, the described and illustrated implementations should beunderstood only as examples, and the illustrated processes can beperformed in a different order, and some actions can be performed inparallel. Additionally, one or more actions can be omitted in variousembodiments; thus, not all actions are required in every implementation.Other process flows are possible.

In this embodiment, process 200 includes an operation that is executedto capture sensor data from one or more sensors included in a mobilecomputing device (block 202). As previously described, the capturedsensor data can include any combination of data captured via sensorsincluded in the mobile computing device during operation of the mobilecomputing device (e.g., during the execution of one or moreapplications). Sensors of a mobile computing device can comprise anycombination of biometric sensors such as sensors for measuring vitalsigns (e.g., temperature, pulse rate, respiration rate, blood pressure,etc.) or for user authentication (e.g., fingerprint scanners, retinascanners, etc.), motion detection sensors such as an accelerometer, agyroscope, or other suitable motion sensing technology to detectmovement of the mobile computing device, geo-location sensors to detectthe location of the mobile computing device, image sensors, audiosensors, etc.

An operation is executed to retrieve user-specific mobile computingdevice data (block 204). The user-specific data can include applicationcontext data for one or more applications, user history data associatedwith one or more applications (e.g., browser history, purchasing historyfrom a marketplace application, etc.), in addition to general userinformation (e.g., login credentials, user email, user phone number,etc.). Each of the plurality of applications can be executed in isolatedsandbox execution environments, as discussed above.

A device data stream can comprise a combination of mobile computingdevice sensor data and user-specific data. Data from a device datastream can be extracted and used to determine a user devicesignature—i.e., matching a data stream to a user using a specificphysical device. Device data streams can therefore be aggregated to forma user data stream. A user may wish to control what data is, or is notincluded, in a device data stream for reasons related to privacy, datausage, etc.

In this embodiment, an operation is executed to retrieve a set of datastream configuration parameters stored in or accessible by the mobilecomputing device (block 206). For example, the data stream parameterscan be stored in memory, or can be retrieved by the mobile computingdevice via a network (e.g., cloud based storage). These data streamconfiguration parameters can define modifications to be made to the dataof a device data stream. For example, a user may wish to remove locationdata from a device data stream, or reduce the accuracy of the locationdata (e.g., reduce the number of decimal degrees for GPS data so thatthe user's exact location cannot be pinpointed past a certain range,such as 0.25 miles); the user may wish to only have sensor data oruser-specific data from certain time periods modified or excluded from adevice data stream; and/or, the user may wish to only modify sensor dataor user-specific data for certain applications. In other words, the usercan configure a device data stream to remove or alter any portion of thecaptured sensor data or the user-specific data. Furthermore, device datastream configuration parameters can be applied for all sensor anduser-specific data related to all applications executed via the mobilecomputing device, regardless of as to their execution environments(e.g., applications executed within isolated sandbox executionenvironments). Application data can also be modified to be aligned withsensor data settings (e.g., application data corresponding to sensordata that is to be alter or removed can also be altered or removed).

An operation is executed to edit the device data stream according to theset of data stream configuration parameters (block 208). The device datastream is then transmitted to a data stream requestor (block 210); inother embodiments, the above described sensor data and user-specificdata can be transmitted separately. Thus, the device data streamreceived by the data stream requestor can include sensor data that ismodified compared to sensor data received by other networked devicesrelated to a specific application or online service (e.g., the onlineservice 140 of FIG. 1 can receive more complete and accurate sensor datacompared to the sensor data received by the data stream requestors 150and 155). The device data stream can be transmitted periodically, uponuser command, in real-time, etc. The device data stream can be sent withdata indicating how it has been modified, what the data stream requestorhas been restricted from viewing, etc.; in other embodiments, the devicedata stream can be sent with no such data.

As discussed above with reference to FIG. 1, a plurality of data steamrequestors (e.g., the requestors 150 and 155 of FIG. 1) can requestdevice data streams of a mobile computing device. In some embodiments,different sets of device data stream configuration parameters can beutilized for different data stream requestors. For example, a user maywish to modify a device data stream differently for specific data streamrequestors; the device data stream can be sent; the device data streamcan be edited differently and sent to each data stream requestor. Thus,process 200 includes an operation executed to determine whether one ormore additional sets of data stream configuration parameters exist forother data stream requestors (block 212). If so, then operations forretrieving device data stream configuration parameters, editing a devicedata stream according to these parameters, and transmitting the editeddevice data stream are re-executed (i.e., blocks 206, 208, and 210) foreach additional set of data stream configuration parameters.

While the above embodiment describes configuring data streams at amobile computing device, other embodiments can configure data streams atan aggregation device (e.g., the data stream storage 120 of FIG. 1)prior to transmission to a data stream requestor. FIG. 3 is a flowdiagram of a process for receiving, configuring, and transmitting adevice data stream according to an embodiment of the disclosure.

Process 300 includes an operation executed to receive a device datastream from a mobile computing device (block 302). The device datastream can comprise a combination of user-specific data includingapplication data from the one or more applications executed via themobile computing device, and sensor data from one or more sensorsincluded in the mobile computing device captured during execution of theone or more applications; in other embodiments, the sensor data anduser-specific data can be received separately.

An operation is executed to receive one or more sets of device datastream configuration parameters from the mobile computing device (block304); this is in contrast to the embodiment of FIG. 2, wherein themobile computing device itself utilizes the device data streamconfiguration parameters. A user may wish to control (i.e., authorize)what data is, or is not included in a device data stream for reasonsrelated to privacy, data usage, etc. Furthermore, a user may wish toconfigure previously received device data streams (e.g., allow locationdata from prior device data streams (where access was restricted) to begiven to data stream requestors. For example, configuration parametersmay be received that indicate that the user wishes to authorizegeo-location data for a specified time period to be accessible byrequestors, eliminating a previous restriction of access to this data.

Received configuration parameters can be used to either update orreplace pre-existing parameters (e.g., updating or replacing a data fileincluding the configuration parameters stored in a memory). Furthermore,different sets of device data stream configuration parameters can bereceived from a user; for example, a user may wish to modify her devicedata streams differently for different data stream requestors. Differentsets of device data stream configuration parameters can also be receivedfrom different data stream requestors. For example, one data streamrequestor may want location data of a device data stream configuredwithin a certain degree of accuracy, while another data stream requestormay want user history data within a certain data range.

An operation is executed to edit the receive device data streamaccording to the set(s) of device data stream configuration parameters(block 306), and transmit the edited device data stream to the datastream requestor (block 308); this is in contrast to the embodiment ofFIG. 2, wherein device data streams are edited prior to theirtransmission from the mobile computing device. An operation is executedto determine whether one or more additional sets of data streamconfiguration parameters exist for other data stream requestors (block310). If so, then operations for editing the received device data streamaccording to these parameters, and transmitting the edited device datastream, are re-executed (i.e., blocks 306 and 308) for each additionalset of data stream configuration parameters.

FIG. 4 is an illustration of a plurality of sets of data streamconfiguration parameters according to an embodiment of the disclosure.As discussed above, sets of data stream configuration parameters can beused configure device data streams for different requestors. Sets ofdata stream configuration parameters can be used configure device datastreams in response to any event (e.g., based on location of the mobilecomputing device, based on applications executed by the mobile computingdevice, dynamically determined by the user, etc.). In this embodiment,the sets of data stream configuration parameters 400 and 450 defineuser-specific data and sensor data parameters for different time periodsof a device data stream (i.e., time periods 410 and 460, respectively).

The set of data stream configuration parameters 400 can be equivalent toor differ in any manner from the set of data stream configurationparameters 450. Each set of data stream configuration parameters 400 and450 can be used by a mobile computing device during the creation and/orediting of a device data stream. For example, the location sensor dataduring the time period 410 can be captured and recorded with normalaccuracy, while the location sensor data during the time period 460 candecrease the accuracy of the captured and recorded sensor data (e.g.,reduce the decimal degrees of longitude/latitude measurements, reduceaccuracy of geo-location data to within a defined range, such as withina quarter-mile, within 100 feet, etc.). In another example, thebiometric sensor data during the time period 410 can be captured andrecorded with normal accuracy, while the biometric sensor data duringthe time period 460 can be disabled. In another example, access to userapplication data (e.g., application transaction history, applicationlogins, etc.) or other user-specific data (e.g., user email accounts,user phone number, etc.) can be restricted. In other embodiments, thesets of data stream configuration parameters 400 and 450 can be used bya device data stream storage device (e.g., a server device separate fromthe mobile computing device generating the device data stream, such asthe data stream storage 120 of FIG. 1) to edit stored data streams priorto their transmission to a requestor.

Thus, data stream configuration parameters can give a user control overthe contents of generated device data streams, thereby alleviatingprivacy/security concerns of the user. Configuration parameters can bedefined such that the device data stream received by the data streamrequestor can include sensor data that is modified compared to sensordata received by other networked devices related to a specificapplication or online service. Furthermore, some device data streamrequestors may wish to provide their own configuration files to users inorder to configure data streams captured by a mobile computing device,thereby ensuring that the data received from the users is useful for agiven purpose. This can include configuring a mobile device to capturedata using specific sensors, enabling data capture at certain times ofthe day or at a pre-determined rate, etc.

In some embodiments, in order to increase user participation insubmitting data streams, users could be compensated for providing devicedata streams to requestors. Compensation may be increased or decreaseddepending on the amount of data in the device data stream beingtransmitted, the types of sensor data included in the device datastream, the user-specific data included in the device data stream, etc.FIG. 5 is a flow diagram of a process for generating a compensationvalue for a user based on a configured device data stream according toan embodiment of the disclosure. This process can be executed by adevice data stream service requestor, or can be executed by a mobilecomputing device to provide a user an estimate for a compensation valuebased on a given configuration of a device data stream.

In this embodiment, process 500 includes executing an operation toreceive device data stream configuration parameters (block 502). Asdescribed above, device data stream configuration parameters can includeparameters to include, exclude, or modify sensor data from one or moresensors included in the mobile computing device captured when the useris using the mobile computing device, user application data from aplurality of applications executed via the mobile computing device,other user-specific data, etc.

An operation is executed to determine an amount of data included in thedevice data stream as configured (block 504). The amount of data can bemeasured in terms of the data size of the device data stream, the lengthof time the device data stream encompasses, etc. An operation isexecuted to determine what sensor data is included in the device datastream as configured (block 506). For example, compensation for a devicedata stream can be affected by the exclusion of certain sensor data(e.g., if the user wishes to exclude biometric data), the accuracy ofthe certain sensor data (e.g., if the location data is based oncell-tower triangulation rather than GPS sensor data), etc. Compensationfor a device data stream can also be affected by the inclusion orexclusion or specific application context data, user history data, etc.Thus, an operation is executed to determine what user-specific data isincluded in the device data stream as configured (block 508).

An operation is executed to determine a compensation amount based on theconfigured device data stream (block 510). This estimate allows the userto adjust the device data stream configuration parameters in order tocorrespondingly adjust a compensation value for providing a device datastreams to a requestor. In some embodiments, this estimate can also beused to inform the user whether certain device data stream configurationparameters are acceptable to a requestor (e.g., an estimatedcompensation value can be “zero” can be given if certain sensor data oruser-specific data is excluded from the device data stream).

FIG. 6 illustrates one example for a computing device in accordance withaspects of the disclosure. In one embodiment, the computing device 600can be a mobile device, which can comprise any of a laptop computer, atablet, a smartphone, a wearable computing device (e.g., a heads-updisplay (HUD) device), etc. The computing device 600 can include aprocessor 602. The processor 602 can be any of a variety of differenttypes of commercially available processors suitable for mobile devices(e.g., an ARM architecture microprocessor, a Microprocessor withoutInterlocked Pipeline Stages (MIPS) architecture processor, or anothertype of processor). A memory 604, such as a random access memory (RAM),a Flash memory, or other type of memory, is typically accessible to theprocessor 602. The memory 604 can be adapted to store an operatingsystem (OS) 606, as well as application programs 608, such as a mobilelocation enabled application that can provide location-based services toa user. The processor 602 can be coupled, either directly or viaappropriate intermediary hardware, to a display 610 and to one or moreinput/output (I/O) devices 612, such as a keypad, a touch panel sensor,a microphone, and the like. In some embodiments, display 610 comprises atouchscreen display capable of functioning as an I/O device 612.Similarly, in some embodiments, the processor 602 can be coupled to atransceiver 614 that interfaces with an antenna 616. The transceiver 614can be configured to both transmit and receive cellular network signals,wireless data signals, or other types of signals via the antenna 616,depending on the nature of the computing device 600. Further, in someconfigurations, a GPS receiver 618 can also make use of the antenna 616to receive GPS signals. The computing device 600 is shown to furtherinclude one or more sensors 620 for capturing at least one of audio data(e.g., via an audio sensor such as a microphone), image data (e.g.,photo, video, or any other type of image data via an image sensor suchas a camera), and/or location, direction, and environmental data (e.g.,temperature, pressure, humidity, orientation, velocity, acceleration,compass bearing, volume, latitude and longitude, etc.).

The application programs 608 of the computing device 600 can furtherinclude one or more browser applications, such as mobile browserapplications, which can be used to provide a user interface to permitthe user to browse information available over the network interface. Theapplication programs 608 can further include one or moreprovider-specific mobile applications (alternatively referred to hereinas “mobile apps”), downloaded (e.g., downloaded by the user from amobile software distribution platform) and resident on the computingdevice 600, that enable the user to access content through the mobileapp in addition to said mobile browser application.

As referred to herein, mobile browsers and mobile apps can describecomputer programs designed to run specifically on mobile devices such assmartphones, tablet computers, other handheld computing devices, etc.Mobile browsers and mobile apps can be designed with consideration tothe constraints (e.g., low-power processors, limited memory, etc.) andfeatures (e.g., location identification capabilities using geo-locationsensors, integrated cellular telephone connectivity, etc.) of mobiledevices. Mobile browsers and mobile apps can also implement mobile userinterface (UI) designs that consider constraints of the screen size ofthe display 610, touchscreen capabilities of the display 610, etc.

Certain embodiments are described herein as including logic or a numberof components, modules, or mechanisms. Modules can constitute eithersoftware modules (e.g., code embodied on a machine-readable medium or ina transmission signal) or hardware modules. A hardware module is atangible unit capable of performing certain operations and can beconfigured or arranged in a certain manner. In example embodiments, oneor more computer systems (e.g., a standalone, client, or server computersystem) or one or more hardware modules of a computer system (e.g., aprocessor or a group of processors) can be configured by software (e.g.,an application or application portion) as a hardware module thatoperates to perform certain operations as described herein.

In various embodiments, a hardware module can be implementedmechanically or electronically. For example, a hardware module cancomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module can also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) can bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired) or temporarilyconfigured (e.g., programmed) to operate in a certain manner and/or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor configured using software, thegeneral-purpose processor can be configured as respective differenthardware modules at different times. Software can accordingly configurea processor, for example, to constitute a particular hardware module atone instance of time and to constitute a different hardware module at adifferent instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules can be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications can beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules can be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module can perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module can then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules can also initiate communications with input oroutput devices and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein can beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors can constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods described herein can be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod can be performed by one or more processors orprocessor-implemented modules. The performance of certain of theoperations can be distributed among the one or more processors, not onlyresiding within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors canbe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors can be distributed across a number of locations.

The one or more processors can also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” (SaaS). For example, at least some of theoperations can be performed by a group of computers (as examples ofmachines including processors), these operations being accessible via anetwork and via one or more appropriate interfaces (e.g., APIs).

Example embodiments can be implemented in digital electronic circuitry,or in computer hardware, firmware, software, or in combinations of them.Example embodiments can be implemented using a computer program product,e.g., a computer program tangibly embodied in an information carrier,e.g., in a machine-readable medium for execution by, or to control theoperation of, data processing apparatus, e.g., a programmable processor,a computer, or multiple computers.

A computer program can be written in any form of programming language,including compiled or interpreted languages, and it can be deployed inany form, including as a stand-alone program or as a module, subroutine,or other unit suitable for use in a computing environment. A computerprogram can be deployed to be executed on one computer or on multiplecomputers at one site or distributed across multiple sites andinterconnected by a communication network.

In example embodiments, operations can be performed by one or moreprogrammable processors executing a computer program to performfunctions by operating on input data and generating output. Methodoperations can also be performed by, and apparatus of exampleembodiments can be implemented as, special purpose logic circuitry(e.g., a FPGA or an ASIC).

A computing system can include clients and servers. A client and serverare generally remote from each other and typically interact through acommunication network. The relationship of client and server arises byvirtue of computer programs running on the respective computers andhaving a client-server relationship to each other. In embodimentsdeploying a programmable computing system, it will be appreciated thatboth hardware and software architectures merit consideration.Specifically, it will be appreciated that the choice of whether toimplement certain functionality in permanently configured hardware(e.g., an ASIC), in temporarily configured hardware (e.g., a combinationof software and a programmable processor), or a combination ofpermanently and temporarily configured hardware can be a design choice.Below are set out hardware (e.g., machine) and software architecturesthat can be deployed, in various example embodiments. It is contemplatedthat any features of any embodiments disclosed herein can be combinedwith any other features of any other embodiments disclosed herein.Accordingly, these any such hybrid embodiments are within the scope ofthe present disclosure.

FIG. 7 is a block diagram illustrating components of a machine,according to some example embodiments, able to read instructions from amachine-readable medium and perform any one or more of the methodologiesdiscussed herein, according to aspects of the disclosure. In particular,FIG. 7 illustrates an exemplary computer system 700 within whichinstructions 724 for causing the machine to perform any one or more ofthe methodologies discussed herein can be executed. In alternativeembodiments, the machine operates as a standalone device or can beconnected (e.g., networked) to other machines. In a networkeddeployment, the machine can operate in the capacity of a server or aclient machine in a server-client network environment, or as a peermachine in a peer-to-peer (or distributed) network environment. Themachine can be a personal computer (PC), a tablet PC, a set-top box(STB), a Personal Digital Assistant (PDA), a cellular telephone, a webappliance, a network router, switch or bridge, or any machine capable ofexecuting instructions (sequential or otherwise) that specify actions tobe taken by that machine. Further, while only a single machine isillustrated, the term “machine” shall also be taken to include anycollection of machines that individually or jointly execute a set (ormultiple sets) of instructions to perform any one or more of themethodologies discussed herein.

The example computer system 700 includes a processor 702 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU) orboth), a main memory 704 and a static memory 706, which communicate witheach other via a bus 708. The computer system 700 can further include avideo display unit 710 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 700 also includes analphanumeric input device 712 (e.g., a keyboard), a UI navigation (orcursor control) device 714 (e.g., a mouse), a disk drive unit 716, asignal generation device 718 (e.g., a speaker), a network interfacedevice 720, and audio/video sensors 728 for capturing audio/video data.

The disk drive unit 716 includes a non-transitory machine-readablemedium 722 on which is stored one or more sets of data structures andinstructions 724 (e.g., software) embodying or utilized by any one ormore of the methodologies or functions described herein. Theinstructions 724 can also reside, completely or at least partially,within the main memory 704 and/or within the processor 702 duringexecution thereof by the computer system 700, the main memory 704 andthe processor 702 also constituting non-transitory, machine-readablemedia. The instructions 724 can also reside, completely or at leastpartially, within the static memory 706.

While the non-transitory machine-readable medium 722 is shown in anexample embodiment to be a single medium, the term “machine-readablemedium” can include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more instructions 724 or data structures.The term “machine-readable medium” shall also be taken to include anytangible medium that is capable of storing, encoding, or carryinginstructions (e.g., instructions 724) for execution by the machine andthat cause the machine to perform any one or more of the methodologiesof the present embodiments, or that is capable of storing, encoding orcarrying data structures utilized by or associated with suchinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, andoptical and magnetic media. Specific examples of machine-readable mediainclude non-volatile memory, including by way of example semiconductormemory devices (e.g., Erasable Programmable Read-Only Memory (EPROM),Electrically Erasable Programmable Read-Only Memory (EEPROM), and flashmemory devices); magnetic disks such as internal hard disks andremovable disks; magneto-optical disks; and compact disc-read-onlymemory (CD-ROM) and digital versatile disc (or digital video disc)read-only memory (DVD-ROM) disks.

The instructions 724 can further be transmitted or received over acommunications network 726 using a transmission medium. The instructions724 can be transmitted using the network interface device 720 and anyone of a number of well-known transfer protocols (e.g., HTTP). Examplesof communication networks include a LAN, a WAN, the Internet, mobiletelephone networks, POTS networks, and wireless data networks (e.g.,WiFi and WiMax networks). The term “transmission medium” shall be takento include any intangible medium capable of storing, encoding, orcarrying instructions (e.g., instructions 724) for execution by themachine, and includes digital or analog communications signals or otherintangible media to facilitate communication of such software.

Said network system components can communicate via any networkingframework. For example, the Open System Interconnection (OSI) modeldefines a networking framework to implement protocols in seven layers.The seven layers, from hardware to application layers, comprise: Layer 1(physical layer), Layer 2 (data link layer), Layer 3 (network layer),Layer 4 (transport layer), Layer 1 (session layer), Layer 6(presentation layer), and Layer 1 (application layer).

The physical layer conveys bit data via network links (e.g., wiredlinks, wireless links) at an electrical and mechanical level. Thephysical layer comprises hardware for sending and receiving data on acarrier, including semiconductor components, wires, cables, cards andother physical structures. The data link layer can encode and decodedata packets into bits, as well as manage transmission protocol anderror handling for the physical layer. The network layer providesswitching and routing functionalities, creating logical paths fortransmitting data from component to component. The network layer canfurther execute addressing, internetworking, error handling, congestioncontrol and packet sequencing functions. The transport layer providestransparent transfer of data between end systems and is responsible forend-to-end error recovery and flow control, while the session layer canestablish, manage and terminate connections between applications.

The presentation layer provides independence from differences in datarepresentation (e.g., encryption) by translating from an applicationformat to a network format, and vice versa. In other words, thepresentation layer transforms data into a form that is acceptable to theapplication layer. The application layer can support computer programapplications and end-user processes, such as identifying communicationpartners, quality of service (QoS) parameters, user authentication andprivacy parameters, data syntax parameters, etc. The application layerprovides application services for file transfers, e-mail and othernetwork software services (e.g., telnet and file transfer protocol(FTP)).

Although an embodiment has been described with reference to specificexample embodiments, it will be evident that various modifications andchanges can be made to these embodiments without departing from thebroader spirit and scope of the present disclosure. Accordingly, thespecification and drawings are to be regarded in an illustrative ratherthan a restrictive sense. The accompanying drawings that form a parthereof show, by way of illustration, and not of limitation, specificembodiments in which the subject matter can be practiced. Theembodiments illustrated are described in sufficient detail to enablethose skilled in the art to practice the teachings disclosed herein.Other embodiments can be utilized and derived therefrom, such thatstructural and logical substitutions and changes can be made withoutdeparting from the scope of this disclosure. This Detailed Description,therefore, is not to be taken in a limiting sense, and the scope ofvarious embodiments is defined only by the appended claims, along withthe full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter can be referred toherein, individually and/or collectively, by the term “invention” merelyfor convenience and without intending to voluntarily limit the scope ofthis application to any single invention or inventive concept if morethan one is in fact disclosed. Thus, although specific embodiments havebeen illustrated and described herein, it should be appreciated that anyarrangement calculated to achieve the same purpose can be substitutedfor the specific embodiments shown. This disclosure is intended to coverany and all adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the above description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R.§1.72(b), requiring an abstract that will allow the reader to quicklyascertain the nature of the technical disclosure. It is submitted withthe understanding that it will not be used to interpret or limit thescope or meaning of the claims. In addition, in the foregoing DetailedDescription, it can be seen that various features are grouped togetherin a single embodiment for the purpose of streamlining the disclosure.This method of disclosure is not to be interpreted as reflecting anintention that the claimed embodiments require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus the following claims are herebyincorporated into the Detailed Description, with each claim standing onits own as a separate embodiment.

What is claimed is:
 1. A non-transitory machine-useable storage mediumembodying instructions which, when executed by a machine, cause themachine to perform a process including operations to: capture sensordata from one or more sensors included in a mobile computing deviceduring execution of at least one of a plurality of applications; edit adevice data stream via the mobile computing device based, at least inpart, on a set of device data stream configuration parameters, thedevice data stream to comprise: the captured sensor data; anduser-specific data separate from the captured sensor data and includingapplication data from the plurality of applications executed via themobile computing device; the device data stream configuration parametersto define modifications for the user-specific data, including theapplication data from the plurality of applications, and the sensor dataof the device data stream; and transmit the edited device data stream toa requesting server device.
 2. The non-transitory machine-usable storagemedium of claim 1, wherein the sensor data comprises sensor data from aplurality of sensors included in the mobile computing device, andwherein the device data stream configuration parameters definemodifications for the sensor data from each of the plurality of sensors.3. The non-transitory machine-usable storage medium of claim 1, whereinthe sensor data comprises data used by the plurality of applications ofthe mobile computing device, and wherein each of the plurality ofapplications are executed in isolated sandbox execution environments ofthe mobile computing device.
 4. The non-transitory machine-useablestorage medium of claim 1, wherein the sensor data comprises at leastone of geo-location data, biometric data of the user, time data,environmental data, image data, and/or audio data.
 5. The non-transitorymachine-useable storage medium of claim 1, wherein the user-specificdata further includes at least one of user login credentials, usercommunication data, and/or user account data for one or more servicesaccessible via the mobile computing device.
 6. The non-transitorymachine-useable storage medium of claim 1, wherein the set of devicedata stream configuration parameters is to define captured sensor dataand/or user-specific data to exclude from the edited device data stream.7. The non-transitory machine-useable storage medium of claim 6, whereinthe set of device data stream configuration parameters is to define theexclusion of captured sensor data and/or user-specific data from theedited device data stream for one or more time periods.
 8. Thenon-transitory machine-useable storage medium of claim 1, wherein theset of device data stream configuration parameters is to configure dataaccuracy of captured sensor data from a sensor included in the editeddevice data stream.
 9. The non-transitory machine-useable storage mediumof claim 1, the process further including operations to: select the setof device data stream configuration parameters from a plurality of setsof device data stream configuration parameters included in the mobilecomputing device.
 10. A method comprising: capturing sensor data fromone or more sensors included in a mobile computing device duringexecution of at least one of a plurality of applications; editing adevice data stream via the mobile computing device based, at least inpart, on a set of device data stream configuration parameters, thedevice data stream to include: the captured sensor data; anduser-specific data separate from the captured sensor data and includingapplication data from the plurality of applications executed via themobile computing device; the device data stream configuration parametersto define modifications for the user-specific data, including theapplication data from the plurality of applications, and the sensor dataof the device data stream; and transmitting the edited device datastream to a requesting server device.
 11. The method of claim 8, whereinthe sensor data comprises at least one of geo-location data, biometricdata of the user, time data, environmental data, image data, and/oraudio data.
 12. The method of claim 8, wherein the user-specific datafurther includes at least one of user login credentials, usercommunication data, and/or user account data for one or more servicesaccessible via the mobile computing device.
 13. The non-transitorymachine-usable storage medium of claim 1, wherein the sensor datacomprises sensor data from a plurality of sensors included in the mobilecomputing device, and wherein the device data stream configurationparameters define modifications for the sensor data from each of theplurality of sensors.
 14. The non-transitory machine-usable storagemedium of claim 1, wherein the sensor data comprises data used by theplurality of applications of the mobile computing device, and whereineach of the plurality of applications are executed in isolated sandboxexecution environments of the mobile computing device.
 15. Anon-transitory machine-useable storage medium embodying instructionswhich, when executed by a machine, cause the machine to perform aprocess including operations to: receive a device data stream from amobile computing device, the device data stream to include:user-specific data including application data from a plurality ofapplications executed via the mobile computing device; and sensor datafrom one or more sensors included in the mobile computing devicecaptured during execution of at least one of the plurality ofapplications and separate from the user-specific data; receive a set ofdevice data stream configuration parameters from the mobile computingdevice, the device data stream configuration parameters to definemodifications for the user-specific data and/or the sensor data of thereceived device data stream; edit the received device data streamaccording to the set of device data stream configuration parameters; andtransmit the edited device data stream to a requesting server device.16. The non-transitory machine-useable storage medium of claim 15,wherein the sensor data comprises at least one of geo-location data,biometric data of the user, time data, environmental data, image data,and/or audio data.
 17. The non-transitory machine-useable storage mediumof claim 15, wherein the user-specific data further includes at leastone of user login credentials, user communication data, and/or useraccount data for one or more services accessed via the mobile computingdevice.
 18. The non-transitory machine-useable storage medium of claim15, wherein the set of device data stream configuration parameters is todefine captured sensor data and/or user-specific data to remove from thereceived device data stream.
 19. The non-transitory machine-useablestorage medium of claim 18, wherein the set of device data streamconfiguration parameters is to define the captured sensor data and/oruser-specific data from the edited device data stream to remove duringone or more time periods.
 20. The non-transitory machine-useable storagemedium of claim 15, the process further including operations to:identify the set of device data stream configuration parameters for therequesting server device from a plurality of sets of device data streamconfiguration parameters.